Upgrade the Grafana plugin's IoTDB Go client to v2.0.10 - #130

Description

The Grafana data source plugin pins github.com/apache/iotdb-client-go/v2 at
v2.0.8, which carries an off-by-one bounds check that v2.0.10 fixes.

In client/tablet.go, both sites in v2.0.8 accept a columnIndex equal to the
number of schemas:

// v2.0.8, :113 and :224
if columnIndex < 0 || columnIndex > len(t.measurementSchemas) {

The corresponding two sites in v2.0.10 reject it:

// v2.0.10, :126 and :259
if columnIndex < 0 || columnIndex >= len(t.measurementSchemas) {

v2.0.10 was published on 2026-08-21. The upgrade also picks up rowIndex
validation in Tablet.SetTimestampAt and IPv6 node URLs in the cluster session.

Why the CI change is in the same pull request

v2.0.10's own go.mod declares go 1.25, where v2.0.8 declared go 1.13.
Bumping the dependency therefore forces the module's go directive to 1.25, and
grafana-plugin.yml pins go-version: "1.21" in all three jobs, two of which
run backend-compile.sh. Changing only go.mod would leave the workflow unable
to build the module, so the two changes are one change.

github.com/apache/thrift moves from v0.17.0 to v0.24.0 as an indirect
consequence of the same upgrade.

Verification

Built and tested locally on macOS with Go 1.26:

go build ./...   exit 0
go vet ./...     exit 0
go test ./...    exit 0   (pkg/plugin ok, 0.028s)

One limitation worth stating plainly: the module's test suite is a single
package that runs in 0.028s, so it does not exercise the thrift surface this
upgrade moves. The build and vet results cover compilation and the obvious
static problems; they are not evidence that the thrift 0.17 to 0.24 jump is
behaviourally safe. If the project would rather take the client bump without the
thrift jump, or wants the plugin exercised against a running Grafana first, I am
happy to do that instead.

go.sum is not in the diff because connectors/grafana-plugin/.gitignore:17
excludes *.sum.

Interaction with open dependabot pull requests

Three open pull requests touch the same go.mod — #103 (otel/sdk), #72
(kin-openapi) and #60 (golang.org/x/net). None of them changes the IoTDB client,
so there is no duplicated work, but whichever of us merges second will need a
rebase, and this change moves the go directive, which is the line most likely
to conflict.